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Ijitroduction 


This  report  summarizes  the  activities  during  the  period  May  1,  1991  through  June  30,  1992.  The 
following  three  sections  describe  results  from  three  major  activities:  a  risk-based  model  of  software 
decision  making,  construction  of  models  for  software  development  processes,  and  verification  of 
safety  properties  of  software  requirements  specifications. 


2  A  Risk-Based  Model  of  Software  Decision  Making 


The  recognition  that  the  “upstream”  activities  (requirements  analysis,  systems  analysis  and  design) 
have  a  greater  impact  upon  total  life  cycle  costs  and  reliability  [27]  than  do  “downstream”  activities 
(coding  and  testing)  [24]  has  led  to  a  greater  emphasis  on  understanding,  formalizing  and  developing 
these  former  activities.  The  ability  to  evaluate  the  implications  of  decisions  in  a  project  before 
coding  permits  easier  and  more  cost  effective  control  over  the  development  process. 

Much  current  research  centers  on  the  development  of  formal  methods  [15]  for  software  design. 
Such  methods  often  focus  on  correct  functionality  of  a  product  [17].  Although  critically  important, 
functionality  is  only  one  attribute  needed  to  evaluate  the  effectiveness  of  a  large  system  development 
[28).  One  must  also  be  concerned  about  scheduling,  costs,  reliability,  performance,  and  numerous 
other  attributes  beyond  those  of  simply  correct  behavior. 

Completely  formal  system  development,  as  an  analog  to  precise  mathematics,  is  unrealistic 
because  of  the  truth  that  mathematics  is  also  plagued  with  errors.  As  the  famous  mathematician 
Richard  W.  Hamming  states  [18]: 

“For  generations,  we  have  patched  up  the  proofs  of  Euler,  Gauss,  and  others  less  famous; 
and  we  expect  future  generations  to  patch  up  proofs  for  our  theorems.  The  myth  that 
there  is  absolute,  ultimate  rigor  in  mathematics  goes  on  despite  evidence  to  the  contrary. 

Why  do  people  believe  that  if  we  are  completely  rigorous  enough,  we  can  get  completely 
reliable  programs?” 

In  addition  to  the  difficultly  of  producing  correct  formal  descriptions  for  computer  systems, 
software  development  is  impacted  by  being  a  human  activity.  Therefore  human  attributes,  as  well 
as  unforeseen  environmental  occurrences,  increase  uncertainty.  Software  project  managers  have 
preconceived  ideas  of  how  to  proceed,  and  corporate  policies  affect  decision  making.  Each  project 
is  developed  under  unique  circumstances;  thus,  forecasting  the  impacts  of  different  decisions  is  very 
difficult. 

Prototyping  has  been  used  as  a  mechanism  for  evaluating  decisions.  The  spiral  model  [6]  is 
often  cited  as  an  alternative  to  the  standard  waterfall  model  as  a  framework  of  a  life  cycle  model 
that  emphasizes  prototyping  and  risk  analysis  of  the  design  process  as  basic  concepts.  However, 
the  spiral  model  is  an  informal  description  of  the  development  process.  What  is  needed  is  a  formal 
theory  that  fleshes  these  detadls.  It  is  towards  this  end  that -this  research  is  focused. 
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An  Appropriate  formal  model  of  software  development  must  include  certain  probabilistic  behav¬ 
ior  to  account  for  some  of  the  uncertainty  inherent  in  the  process.  We  have  developed  a  process 
model  by  adapting  the  functional  correctness  model  [25]  (i.e.,  related  to  denotational  semantics  and 
the  Vienna  Development  Method  (VDM))  with  risk  reduction  features  borrowed  from  economic  de¬ 
cision  theory. 

Given  alternative  design  strategies,  we  have  been  developing  a  theory  of  risk  analysis  that 
permits  the  software  manager  to  evaluate  different  designs  and  determine  the  probable  success  or 
failure  of  each.  It  is  realistic  in  that  it  permits  each  manager  or  organization  to  tailor  the  model 
to  his  own  level  of  risk  behavior.  A  model  like  this  potentially  can  be  used  to  formalize  the  spiral 
model  and  allow  for  transition  of  this  method  to  new  Department  of  Defense  and  other  industrial 
software  environments  for  improved  management  of  the  development  process. 


Developing  the  Model 

Formal  specifications  for  complex  systems  need  to  go  beyond  functionality.  We  must  consider 
attributes  like  performance,  schedule,  resource  usage  along  with  functionality,  in  order  to  appropri¬ 
ately  decide  on  the  best  development  strategy.  In  addition,  software  development  -  like  zmy  other 
management  approach  -  must  weigh  various  decisions  based  upon  unknown  future  events  in  order 
to  decide  on  an  appropriate  course  of  action  at  the  present. 

This  strongly  suggests  that  techniques  from  decision  theory,  economic  theory  and  various  risk 
analysis  models  can  play  a  role  in  software  decision  making.  We  have  begun  to  develop  such  a 
theory.  Our  model  has  the  following  characteristics: 


•  We  studied  the  role  specifications  play  in  the  design  of  software  and  developed  a  model  of  the 
decisions  that  need  to  be  made  [26]. 

•  We  defined  the  concept  of  a  viable  specification  as  a  multidimensional  extension  to  the  usual 
definition  of  functional  correctness  [25].  We  defined  an  evaluation  strategy  based  upon  a  met¬ 
ric  we  call  the  performance  level  in  order  to  evaluate  alternative  designs  to  a  give  specification 
[10]. 

•  We  extended  the  model  to  handle  risk  [12].  That  is,  when  there  axe  alternative  states  of 
nature,  with  a  given  probability  distribution,  we  use  equilibrium  probabilities  to  query  the 
software  manager  in  order  to  determine  the  performance  level  for  taking  each  of  the  possible 
approaches.  This  model  allows  for  variations  and  alternative  strategies  of  different  software 
managers.  In  particular  it  can  be  tailored  to  the  risk-seeking  and  risk-adverse  manager  to  “ 
create  development  strategies  best  suited  for  their  Individual  tastes  [11]  [13]. 

•  We  built  a  prototype  implementation  called  Selector  vising  these  ideas.  The  software  manager  ^ 
provides  the  set  of  attributes  and  for  each  potential  solution  provides  the  ordinal  ranking  of 
how  well  that  solution  meets  the  specifications.  Selector  guides  the  manager  into  evaluating 
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various  risks  and  seeks  to  determine  which  form  of  prototype  provides  the  most  information  ^ . 

[12]. 
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TheHbllowing  briefly  summarizes  this  development. 

Assume  that  specifications  for  a  program  are  vectors  of  attributed,  including  functionality  as 
one  of  the  elements  of  the  vectors.  Let  X  and  V  be  vectors  of  attributes  that  specify  alternative 
solutions  to  a  specification  B.  Let  S  be  a  vector  of  objective  functions  with  domain  being  the  set 
of  specification  attributes  and  range  [0..1j.  We  call  5,-  a  scaling  function  and  it  is  the  degree  to 
which  a  given  attribute  meets  its  goal.  We  state  that  X  solvcsg  Y  if  'rfi,  Si{Xi)  >  Design  x 

is  viable  (i.e.,  is  correct)  with  respect  to  specification  B  and  scaling  function  vector  S  if  and  only 
if  P  solvess  B.  ,  ^  ± 

Each  attribute  may  not  have  the  same  importance.  Assume  a  vector  of  weights  W  called 
constraints  such  that  each  u?,-  €  [0..1]  and  =  1*  The  performance  level  merges  multiple  scaled 
attributes  and  their  constraints.  Given  specification  vector  X,  scaling  function  S  and  constraints 

W,  the  performance  level  is  given  by:  PL(X,S,W’)  =  by 

Given  a  specification  vector  B,  scaling  vector  S,  constraints  W  and  potential  solutions  i  and^ 
y,  X  improves  Y  with  respect  to  {B,  5,  W)  if  and  only  if: 


1.  X  solvess  B  and  Y  solvess  B 

2.  PL(X,  5,  W)  >  PL(Y,  5,  W). 


Since  future  behavior  is  not  known  during  development,  there  is  a  degree  of  uncertainty  to  this 
process.  We  can  use  appropriate  techniques  from  decision  theory  to  evaluate  potential  solutions. 
We  represent  the  performance  level  as  a  matrix  PL  where  PLij  is  the  performance  level  for  solution 
i  under  state  of  nature  j.  As  before,  the  performance  levels  give  a  measure  of  how  good  a  system 
is.  We  can  approximate  this  by  defining  the  entries  PLij  of  performance  level  matrix  PL  as  the 
payoff  (e.g.,  monetary  value)  for  solution  i  under  state  j. 

When  the  probability  for  each  state  of  nature  can  be  estimated,  we  can  use  expected  values  to 
achieve  cm  estimated  performance  level.  Given  probability  distribution  vector  P,  where  p,-  is  the 
probability  that  state  of  nature  sU  is  true,  the  expected  payoff  for  alternative  X*  is  ^ven  by: 

Pj  (1) 

j 

Use  the  decision  rule:  Choose  X'  which  maximizes  w,-  or: 

Pj)  (2) 

} 

Risk  aversion  plays  an  important  role  in  decision  making.  This  implies  subjective  behavior  on 
the  part  of  the  software  manager.  We  assume  that  the  following  reasonable  behavior  rule  applies: 


•  Decomposition:  Given  three  payoffs  a  <  b  <  c,  there  exists  a  probability  p  such  that  the 
decision  maker  is  indifferent  to  the  choice  of  a  guarantee  of  6,  and  the  choice  of  getting  c 
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with  probability  p  and  getting  o  with  probability  \  -  p.  We  shall  refer  to  this  probability  as 
decomp{a,b,c). 


Let  plo  be  the  minimal  value  in  our  payoff  PL  and  let  pi*  be  the  maximal  value.  We  decompose 
each  plij  as  e,_j  =  decomp{plo,plij,pl*).  This  decomposition  creates  an  equivalent  pair  of  payoffs 
{plo,  pi*},  with  probability  e,j  of  getting  the  more  desirable  pi*.  Any  element  Cij  will  satisfy  the 
following  inequality: 

p/o  X  (1  -  €ij)  +  pi*  X  >  plij  (3) 

The  difference  between  the  two  sides  of  this  equation  reflects  the  manager’s  degree  of  risk  averseness. 
If  the  two  sides  are  equal,  risk  analysis  reduces  to  the  expected  value. 

A  prototype  implementation  of  our  evaluation  strategy  has  been  built  in  C.  A  manager  enters 
a  table  of  attributes  and  initial  constraints  and  then  executes  Selector.  The  manager  is  prompted 
for  the  various  equilibrium  probabilities,  which  determine  the  risk  averseness  behavior  of  that 
particular  individual  as  well  as  objective  characteristics  of  the  particular  solution  being  considered. 
The  tool  then  computes  the  performance  level  for  each  potential  solution,  computes  the  potential 
gain  from  prototyping  and  offers  advice  on  which  attribute  would  provide  the  maximum  gain  if  it 
were  investigated. 


Validating  the  Model 

Given  the  various  unknowns  in  the  states  of  nature,  the  software  manager  may  choose  to  get 
more  information  with  a  prototype  so  that  a  better  final  decision  can  be  made.  However,  before 
undertaking  the  procedure  to  extract  more  information,  one  should  be  sure  that  the  gain  due  to  the 
information  will  outweigh  the  cost  of  obtaining  it.  Here,  we  try  to  establish  an  absolute  boundary: 
What  is  the  value  of  perfect  information? 

If  we  know  what  is  the  true  state  of  nature,  we  can  choose  the  alternative  that  gives  the  highest 
performance  level; 

^  =  IZPf  xmajcp/ij  (4) 

j 

What  is  the  value  of  this  perfect  information?  The  difference  between  our  expected  value 
and  this  improved  performance  level  is  the  maximum  our  prototype  can  achieve,  and  still  be  cost 
effective. 

We  can  now  merge  this  into  the  definition  of  the  spiral  model.  Assume  we  build  a  prototype 
to  test  which  state  of  nature  will  be  true.  Given  prototype  P  and  specification  fl,  P  is  a  valid 
prototype  if  P  solves  B  for  a  subset  of  the  attributes  of  B.  Depending  upon  the  cost  of  P  and  the 
potential  gain,  we  have  the  decision  procedure  that  we  need  to  make  an  effective  spiral  software 
process  model. 
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3  Modeling  Software  Engineering  Experience 


We  have  been  working  on  the  notion  of  an  improved  approach  to  software  development  which 
reuses  all  forms  of  software  knowledge  to  improve  the  software  process  and  product.  Based  upon 
the  Quality  Improvement  Paradigm  (QIP),  we  have  designed  an  evolutionary  approach  to  software 
development  that  creates  packages  of  experience  for  an  organization  that  can  be  reused  to  improve 
their  software  production.  The  steps  of  the  QIP  are: 


•  Characterize  the  current  project  and  its  environment. 

•  Set  the  quantifiable  goals  for  successful  project  performance  and  improvement. 

•  Choose  the  appropriate  process  model  and  supporting  methods  and  tools  for  this  project. 

•  Execute  the  processes,  construct  the  products,  collect  and  validate  the  prescribed  data,  and 
analyze  it  to  provide  real-time  feedback  for  corrective  action. 

•  Analyze  the  data  to  evaluate  the  current  practices,  determine  problems,  record  findings,  and 
make  recommendations  for  future  project  improvements. 

•  Package  the  experience  in  the  form  of  updated  and  refined  models  and  other  forms  of  struc¬ 
tured  knowledge  gained  from  this  and  prior  projects  and  save  it  in  an  experience  base  for 
future  projects. 


The  Experience  Factory 

The  QIP  requires  the  support  of  an  organization  that  packages,  stores  and  retrieves  information.  To 
support  the  QIP,  the  Experience  Factory  concept  was  created.  The  Experience  Factory  represents 
a  form  of  laboratory  environment  for  software  development  where  models  can  be  built  and  provide 
direct  benefit  to  the  projects.  It  represents  an  organizational  structure  that  supports  the  QIP  by 
providing  support  for  learning  through  the  accumulation  of  experience,  the  building  of  experience 
models  in  an  experience  base,  and  the  use  of  this  new  knowledge  and  understanding  in  current  and 
future  project  developments. 

The  Experience  Factory  concept  supports  a  software  evolution  model  that  takes  advantage  of 
newly  learned  and  packaged  experiences;  a  set  of  processes  for  learning,  packaging,  and  storing 
experience;  and  the  integration  of  these  two  sets  of  functions.  As  such,  it  requires  separate  logical 
or  physical  organizations  with  different  focuses/priorities,  process  models,  and  expertise  require¬ 
ments.  It  consists  of  a  Project  Organization  whose  focus  is  product  delivery  and  an  Experience 
Factory  whose  focus  is  to  support  project  developments  by  analyzing  and  synthesizing  all  kinds 
of  experience,  acting  as  a  repository  for  such  experience,  and  supplying  that  experience  to  various 
projects  on  demand.  The  Experience  Factory  packages  experience  by  building  informal,  formal  or 
schematized,  and  “productized”  models  and  measures  of  various  software  processes,  products,  and 
other  forms  of  knowledge  via  people,  documents,  and  automated  support. 
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Our-research  paradigm  has  been  focused  on  the  storage,  access  and  integration  of  them  in  a 
form  of  experience  base  and  formalizing  the  development  of  data  models. 


TAME  Model  Building 

Since  one  of  the  goals  of  the  Experience  Factory  is  to  build  models,  we  have  developed  methods  to 
do  better  data  modeling  for  the  software  en£;;ineering  domain.  In  order  to  plan,control  and  evaluate 
the  software  development  process,  we  need  to  collect  data,  analyze  them  and  build  accurate,  easy 
to  use  and  interpretable  models.  Building  software  engineering  models  is  a  difficult  task.  The  data 
collected  is  very  often  noisy  and  heterogeneous,  presenting  many  problems  with  respect  to  model 
construction  (e.g.  interdependencies,  outliers,  complex  relationships).  Measurement  theory,  statis¬ 
tics  and  machine  learning  provide  many  alternative  modeling  techniques  and  processes.  However, 
mainly  because  of  the  lack  of  data,  few  experiments  in  our  field  have  been  performed  in  order 
to  study,  compare,  validate  and  integrate  the  various  approaches  for  standard  software  modeling 
issues  (e.g.  detecting  high  risk  components). 

Classical  techniques  (e.g.,  regression  analysis)  are  not  always  well  suited  for  software  engineering 
data  analysis.  To  build  effective  models  in  the  Experience  Factory,  we  developed  a  modeling 
approach  for  analyzing  software  engineering  data,  called  Optimized  Set  Reduction  (OSR),  which 
adaresses  many  of  the  problems  associated  with  the  usual  approaches.  OSR  is  based  on  both 
statistics  and  machine  learning  techniques.  It  generates  a  set  of  patterns  relevant  to  predictions  to 
be  made  about  an  object  or  to  general  trends  in  an  entire  data  set. 

The  goal  of  the  OSR  algorithm  is  to  determine  which  subsets  of  experiences  (i.e.  pattern  vectors) 
from  the  historical  data  set  provide  the  best  characterizations  of  the  object  to  be  assessed.  For 
example,  assume  we  want  to  assess  a  particular  characteristic  of  an  object  (e.g.  the  fault  density  of 
a  component).  We  refer  to  this  characteristic  as  the  dependent  variable  (Y).  We  try  to  determine 
which  subsets  of  the  data  set  yield  the  “best”  probability  distributions  on  the  Y  range.  A  good 
probability  distribution  on  the  Y  value  domain  is  one  that  a  concentrates  a  large  number  of  pattern 
vectors  in  either  a  small  part  of  the  range  (Y  is  continuous)  or  a  small  number  of  dependent  variable 
categories  (Y  is  discrete).  One  of  the  commonly  used  probability  distribution  evaluation  functions 
is  the  information  theory  entropy  H.  Each  of  the  subsets  yielding  “optimal”  distributions,  referred 
to  as  optimal  subsets,  are  characterized  by  a  set  of  conditions,  or  predicates  which  axe  true  for  all 
pattern  vectors  in  that  subset.  Each  set  of  predicates  characterizing  a  subset  is  called  a  pattern. 

Methods  have  been  developed  for  using  OSR  for  prediction,  risk  management  and  quality  evalu¬ 
ation.  An  experiment  demonstrating  the  effectiveness  of  the  technique  for  software  cost  estimation 
is  described  in  [7],  which  will  appear  in  the  IEEE  Transactions  on  Software  Engineering  as  part  of 
the  special  issue  on  software  modelling  and  measurement. 

Based  upon  our  need  to  develop  and  evaluate  data  analysis  techniques  for  building  software 
engineering  models,  we  have  also  worked  on  the  problem  of  detecting  high  risk  software  components 
using  two  modeling  approaches  based  on  totally  different  principles  and  theories.  The  first  one  is  the 
logistic  regression  approach,  a  fairly  standard  technique  for  classification  in  the  field  of  statistics. 
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The  second  one  has  been  OSR.  We  have  compared  the  resuks  obtained  by  the  two  modeling 
approaches  from  several  perspectives.  We  tried  to  determine  how  accurate  they  are  in  terms  of 
classification  correctness  (i.e.  high  risk  over  low  risk  component)  and  completeness  (i.e.  percentage 
of  high  risk  components  detected).  We  also  looked  at  understandability  issues  such  as  those  listed 
below. 

•  What  kind  of  insights  does  the  model  yield  with  respect  to  the  studied  software  problem? 

•  How  does  the  model  help  software  engineers  to  refine  their  qualitative  reasoning  rules  with 
respect  to  project  management  based  on  empirical  evidence? 

OSR  has  shown  to  be  very  effective  for  model  building.  The  results  of  this 

work  [8]  will  be  partially  presented  at  the  International 

Conference  on  Software  Reliability  in  October  of  this  year.  Another  article  is  in  preparation  in 
order  to  complete  and  enhance  the  results  presented  at  the  conference. 


4  Verifying  Requirements  Properties 

A  software  requirements  document  is  usually  the  first  description  of  a  system’s  required  behavior. 
Errors  in  this  document  are  difficult  and  expensive  to  correct  if  they  are  propagated  to  the  design 
phase  (or  worse,  to  the  implementation)  [22].  While  reviews  by  experienced  systems  designers 
are  effective  for  improving  the  quality  of  requirements,  significant  improvements  can  be  made  if 
automated  analysis  techniques  can  be  applied  to  formal  system  descriptions. 


SCR  Requirements  Specification 

Software  Cost  Reduction  (SCR)  requirements  specifications  [1,  19]  describe  a  system’s  modes  of 
operation  and  events  that  cause  the  system  to  change  modes.  SCR-style  requirements  specifications 
model  a  system’s  behavior  as  a  set  of  finite-mode  machines  that  execute  concurrently.  The  basic 
concepts  in  these  requirements  are  modes,  mode  classes,  and  events. 

•  A  mode  is  a  set  of  system  states  that  share  a  common  property. 

•  A  mode  class  is  a  set  of  modes,  and  the  union  of  the  modes  in  a  mode  class  must  cover  the 
system’s  state  space. 

•  A  mode  transition  occurs  between  modes  in  the  same  mode  class  as  a  result  of  system  state 
changes. 

•  Mode  transitions  are  specified  by  conditions  and  events,  which  comprise  the  machine’s  input 
language. 
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The  system  is  in  exactly  one  mode  of  each  mode  class  at  all  times.  Informally,  the  modes  and  tran¬ 
sitions  in  each  mode  class  form  a  mode-machine  that  describes  one  aspect  of  a  system’s  behavior, 
and  the  transitional  behavior  of  the  entire  system  is  defined  by  the  composition  of  all  the  system’s 
mode-machines. 

Conditions  are  boolean  state  variables,  and  a  system’s  state  space  is  the  set  of  all  possible 
combinations  of  its  conditions’  values.  Partitioning  the  state  space  into  modes  reduces  the  size  of 
requirements.  A  mode  transition  is  activated  by  the  occurrence  of  an  event,  which  represents  the 
point  in  time  when  a  condition’s  value  changes.  For  example,  event 

@T(CondJ)  WHEN  [Cond2] 

occurs  when  condition  Condi  becomes  true  while  condition  Cond2  is  true.  More  complex  events 
can  be  created  from  simpler  events  and  conditions  using  boolean  operators. 

A  mode  transition  condition  specifies  the  event  that  triggers  the  transition.  Two  transitions 
from  the  same  mode  are  simultaneously  enabled  if  their  trigger  events  occur  at  the  same  instant. 
In  such  a  case,  the  mode  machine  is  nondeterministic,  and  the  activation  of  either  transition  (but 
not  both)  satisfies  the  requirements. 

The  tabular  format  of  SCR-style  requirements  specification  is  both  easy  to  write  and  easy  to 
understand.  Even  so,  a  requirements  designer  will  often  augment  the  behavioral  specification  with 
a  set  of  global  constraints  on  the  system’s  behavior.  The  purpose  of  the  global  constraints  is  to 
give  a  compact  view  of  a  system’s  invariant  properties  that  may  otherwise  be  diflficult  to  extract 
from  a  behavioral  specification.  Sometimes,  the  global  constraints  are  explicitly  included  in  the 
requirements  document,  though  they  may  not  be  expressed  mathematically;  their  format  can  range 
from  logical  formulas  [20]  to  natural  language  sentences  [1].  Other  times,  they  are  not  included  in 
the  requirements  document,  but  are  implicit  assumptions  made  by  the  requirements  designer  [23]. 


Model  Checking 

If  a  system’s  behavioral  requirements  can  be  represented  as  a  set  of  communicating  finite-state 
machines,  Clarke  et.  al.  [14]  have  devised  a  model  checking  algorithm  to  determine  which  states  of 
the  system  satisfy  temporal  logic  assertions.  We  use  an  improved  version  of  Claxke’s  original  model 
checking  system,  called  MCB  [9],  as  our  model  checker.  Formulas  to  be  checked  are  expressed  in  a 
propositional  branching-time  logic  called  computational  tree  logic  (CTL),  whose  operators  permit 
explicit  quantification  over  all  possible  futures. 

Most  elements  of  the  SCR  requirements  model  correspond  naturally  to  elements  of  finite-state 
machines.  However,  there  is  no  natural  model  of  events  because  of  the  differences  between  mode 
transitions  and  state  transitions.  State  transitions  occur  based  on  the  current  state  and  the  current 
values  of  the  input  conditions.  Mode  transitions  occur  simultaneously  with  events;  the  system 
spends  zero  time  in  a  mode  once  one  of  its  transitions  has  been  activated.  Therefore,  we  need  to 
be  able  to  represent  changes  in  condition  values  and  ensure  that  state  transitions  are  activated  by 
these  value  changes. 


9 


r- 1 


To  model  events,  we  can  represent  modes  as  two  states:  a  mode  state  and  a  trigger  state. 
The  mode  state  represents  the  system  when  it  is  in  a  mode;  all  transitions  into  the  original  system 
mode  are  modeled  as  transitions  into  the  representative  mode  state.  The  trigger  state  represents  the 
system  2is  it  leaves  a  mode;  all  transitions  leaving  the  original  mode  are  represented  as  transitions 
leaving  the  associated  trigger  state.  We  annotate  ♦he  trigger  state’s  transitions  with  the  original 
mode’s  transition  conditions,  and  we  annotate  the  transition  from  the  mode  state  into  the  trigger 
state  with  the  negation  of  the  transitions’  trigger  events. 

We  used  our  analysis  technique  to  analyze  two  requirements  documents,  one  for  an  automobile 
cruise  control  system  and  one  for  a  water-level  monitoring  system  [3].  These  requirements  were 
written  by  other  groups  of  researchers.  We  transformed  these  systems’  requirements  into  finite-state 
machines,  rephrased  required  safety  properties  as  logical  formulas,  and  verified  the  formulas  using 
the  MCB  model  checker.  In  both  studies,  we  found  discrepancies  between  the  systems’  requirements 
specifications  and  their  safety  assertions. 

While  this  technique  is  quite  promising,  only  the  model  checking  portion  is  currently  automated. 
The  translation  of  SCR  requirements  to  finite-state  models  is  still  an  error-prone  manual  process. 
This  proposal  will  fund  work  to  automate  this  translation,  extend  the  safety  properties  that  can 
be  verified  to  include  assertions  about  time  bounds,  and  provide  a  way  to  do  static  analysis  of 
implementations  to  determine  if  they  are  consistent  with  requirements. 
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References  2-5,  7-8,  10-13,  16-17,  21,  and  24-28  report  results  of  our  AFOSR-sponsored  research. 
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